Public ledger authentication system

ABSTRACT

Systems and methods for public ledger authentication includes receiving a first previous authentication public ledger address and a first current authentication public ledger address from a user. A verified static user key is identified in a public ledger using the first previous authentication public ledger address. A second current authentication public ledger address is then provided to the user for use in the current authentication attempt. Authentication attempt information is determined that includes a number of authentication attempts by the user, and used in a hash operation with the verified static user key to generate a first user authentication key. A second user authentication key is retrieved from the public ledger that was sent from the first current authentication public ledger address to the second current authentication public ledger address in a transaction, and the user is authenticated if the second user authentication key matches the first user authentication key.

CROSS REFERENCE TO RELATED APPLICATION

The present application is a continuation-in-part of U.S. patentapplication Ser. No. 15/098,079 filed Apr. 13, 2016, entitled “PUBLICLEDGER AUTHENTICATION SYSTEM,” the disclosure of which are incorporatedherein by reference.

BACKGROUND Field of the Disclosure

The present disclosure generally relates to online and/or mobilepayments and more particularly to a public ledger authentication systemthat may be used to authenticate to an online and/or mobile paymentsystem.

Related Art

More and more consumers are purchasing items and services overelectronic networks such as, for example, the Internet. Consumersroutinely purchase products and services from merchants and individualsalike. The transactions may take place directly between a conventionalor on-line merchant or retailer and the consumer, and payment istypically made by entering credit card or other financial information.Transactions may also take place with the aid of an on-line or mobilepayment service provider such as, for example, PayPal, Inc. of San Jose,Calif. Such payment service providers can make transactions easier andsafer for the parties involved. Purchasing with the assistance of apayment service provider from the convenience of virtually anywhereusing a mobile device is one main reason why on-line and mobilepurchases are growing very quickly.

Online and/or mobile payment systems typically require authentication bytheir users in order to ensure that a user accessing a payment accountand executing payment transactions using that payment account areauthorized to do so. Conventional authentication systems typicallyrequire a user that is attempting to access a payment account and/orexecute a payment transaction to provide authentication credentials inthe form of a username and password, a biometric identifier (e.g., athumb scan), and/or other conventional authentication credentials knownin the art. However, many users utilize easily guessed authenticationcredentials that compromise the security of their payment account, or donot have biometric devices that allow for the higher security biometricidentifier authentication discussed above.

Thus, there is a need for an improved authentication system.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A is a flow chart illustrating an embodiment of a registrationmethod for registering with a public ledger authentication system;

FIG. 1B is a flow chart illustrating an embodiment of a authenticationmethod for authenticating using a public ledger;

FIG. 2 is a schematic view illustrating an embodiment of an electroniccoin or authentication token;

FIG. 3 is a schematic view illustrating an embodiment of a cryptocurrency public ledger or authentication public ledger;

FIG. 4 is a schematic view illustrating an embodiment of a public ledgerauthentication system;

FIG. 5 is a schematic view illustrating an embodiment of a user deviceused in the public ledger authentication system of FIG. 4;

FIG. 6 is a screen shot of an embodiment of a user device displaying anauthentication screen;

FIG. 7 is a flow chart illustrating an embodiment of a anonymousdonation method.

FIG. 8 is a schematic view illustrating an embodiment of an anonymousdonation system.

FIG. 9 is a schematic view illustrating an embodiment of a networkedsystem;

FIG. 10 is a perspective view illustrating an embodiment of a userdevice;

FIG. 11 is a schematic view illustrating an embodiment of a computersystem; and

FIG. 12 is a schematic view illustrating an embodiment of a systemprovider device.

Embodiments of the present disclosure and their advantages are bestunderstood by referring to the detailed description that follows. Itshould be appreciated that like reference numerals are used to identifylike elements illustrated in one or more of the figures, whereinshowings therein are for purposes of illustrating embodiments of thepresent disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION

Some embodiments of the present disclosure provide systems and methodsfor authentication via a public ledger to access, for example, afinancial account, a website, and/or any other secure system known inthe art. The public ledger may be dedicated for authentication (e.g., an“authentication public ledger), or may be provided as part of a cryptocurrency public ledger, to allow for the authentication of users tosecure systems by a system provider. The public ledger authenticationdescribed herein includes an registration method in which each of a userand a system provider perform a common hash operation on useridentification information (e.g., a user name, a user address, a userphone number, a user date of birth, a user social security number, etc.)to generate respective first and second static user keys. The systemprovider may identify a first registration public ledger address to theuser, the user may identify a second registration public ledger addressto the system provider, and the user may then subsequently send thefirst static user key to the first registration ledger address from thesecond registration public ledger address in a transaction in the publicledger. The system provider may then access that registration ledgeraddress via the public ledger (using the identifications of the firstand second registration ledger addresses to reference the public ledger)to retrieve the first static user key and register the user with thesystem if the first static user key matches the second static user keygenerated by the system provider. The first static user key in thepublic ledger then becomes a verified static user key in the publicledger that may be used for subsequent authentication of the user, andthe system provider may erase or otherwise discard the useridentification information and the second static user key.

Following registration, the user may authenticate to the secure systemin an authentication method by sending the system provider a firstprevious authentication public ledger address that was used in aprevious authentication attempt and a first current authenticationpublic ledger address for use in the current authentication attempt. Thesystem provider may use the first previous authentication public ledgeraddress to access a database that identifies previous authenticationpublic ledger addresses used by the user in previous authenticationattempts and allows for the determination of a number of previousauthentication attempts by the user, and identify the verified staticuser key in the public ledger. The system provider may then perform ahash operation using the number of previous authentication attempts andthe verified static user key to generate a first user authenticationkey. The system provider then provides the user a second currentauthentication public ledger address for use in the currentauthentication attempt. The user may also perform the hash operationusing the number of previous authentication attempts and the verifiedstatic user key (both of which may be stored by the user in atransaction wallet) to generate a second user authentication key, andsend the second user authentication key from the first currentauthentication public ledger address to the second currentauthentication public ledger address in a transaction on the publicledger. The system provider may then check the transaction sent from thefirst current authentication public ledger address to the second currentauthentication public ledger address in the public ledger to retrievethe second user authentication key and authenticate the user with thesystem if the second user authentication key matches the first userauthentication key generated by the system provider.

Referring now to FIGS. 1A, 1B, 2, and 3, a method 100 for providingpublic ledger authentication is illustrated. In the illustratedembodiment, the method 100 includes a registration sub-method 100A andan authentication sub-method 100B. In some embodiments of the method 100described below, one or more system provider devices may operate toperform or enable the method 100. For example, a distributed group ofdevices may operate to maintain the public ledger discussed below bycreating (a.k.a., “mining”) a distributed crypto currency, processingtransactions involving the distributed crypto currency, and/or otherwiseperforming actions that provide the public ledger utilized in the method100 as detailed below. In a specific example, a payment service providersuch as, for example, PayPal, Inc. of San Jose, Calif., may utilize apayment service provider device to perform the method 100 discussedbelow, and in some embodiments may operate in cooperation with one ormore other system providers (via their system provider devices), payees(via their payee devices), payers (via their payer devices), and/orusers (via their user devices) to perform the method 100 discussedbelow. However, these embodiments are meant to be merely exemplary, andone of skill in the art in possession of the present disclosure willrecognize that a wide variety of system providers may operate, alone ortogether, to provide the systems and methods discussed herein withoutdeparting from the scope of the present disclosure.

Referring now to FIG. 2, an embodiment of an electronic coin 200 isillustrated and described briefly for reference to the public ledgerused in some embodiments of the method 100 discussed below. In thoseembodiments, a crypto currency system associated with the presentdisclosure defines an electronic coin as a chain of digital signaturesprovided by previous owners of the electronic coin to subsequent ownersof the electronic coin. In the illustrated embodiment, the electroniccoin 200 is owned by an owner 202, and FIG. 2 illustrates how theelectronic coin 200 is defined by the digital signatures of the previousowners 204, 206, and 208. Specifically, in transaction A, a hash of thepublic key of owner 206 (i.e., the owner receiving, as a result oftransaction A, an electronic coin 200 ₁ defined by digital signaturesprovided up to transaction A) and the previous transaction (notillustrated, but occurring prior to transaction A) was signed by owner208 (i.e., the owner providing, as a result of transaction A, theelectronic coin 200 ₁ defined by digital signatures provided up totransaction A) and added to an initial electronic coin (which wasdefined by digital signatures provided up to the transaction prior totransaction A) such that the electronic coin 200 ₁ was transferred toowner 206.

Similarly, in transaction B, a hash of the public key of owner 204(i.e., the owner receiving, as a result of transaction B, an electroniccoin 200 ₂ defined by digital signatures provided up to transaction B)and transaction A was signed by owner 206 and added to the electroniccoin 200 ₁ such that the electronic coin 200 ₂ was transferred to owner204. Similarly, in transaction C, a hash of the public key of owner 202(i.e., the owner receiving, as a result of transaction C, the electroniccoin 200 defined by digital signatures provided up to transaction C) andthe transaction B was signed by owner 204 and added to the electroniccoin 200 ₂ such that the electronic coin 200 was transferred to owner202. As is understood in the art, any payee receiving an electronic coin(e.g., owner 206 in transaction A, owner 204 in transaction B, and owner202 in transaction C) can verify the signatures to verify the chain ofownership of the electronic coin. In the discussion below, it should beunderstood that the term “electronic coins” is used to encompass anyamount of electronic coins, and in the embodiments discussed below willtypically be small fractions of a coin (e.g., 0.00000001 electroniccoins) or some amount of a coin with relatively low value.

Referring now to FIG. 3, an embodiment of a crypto currency publicledger 300 is illustrated and described briefly for reference to thepublic ledger used in some embodiments of the method 100 discussedbelow. Conventionally, the crypto currency public ledger 300 operates toverify that payers transferring an electronic coin (e.g., referring backto FIG. 2, owner 206 in transaction A, owner 204 in transaction B, andowner 202 in transaction C) did not “double-spend” (e.g., sign anyprevious transactions involving) that electronic coin. To produce thecrypto currency public ledger 300, a distributed network of devicesoperates to agree on a single history of transactions in the order inwhich they were received such that it may be determined that atransaction between a payer and a payee using an electronic coin is thefirst transaction associated with that electronic coin. Each device inthe distributed network operates collect new transactions into a block,and then to increment a proof-of work system that includes determining avalue that when hashed with the block provides a required number of zerobits.

For example, for a block 302 that includes a plurality of transactions302 a, 302 b, and up to 302 c, a device in the distributed network mayincrement a nonce in the block 302 until a value is found that gives ahash of the block 302 the required number of zero bits. The device maythen “chain” the block 302 to the previous block 304 (which may havebeen “chained” to a previous block, not illustrated, in the samemanner). When devices in the distributed network find the proof-of-workfor a block, that block (e.g., block 302) is broadcast to thedistributed network, and other devices in the distributed network willaccept that block if all the transactions in it are valid and notalready spent (which may be determined by creating the next block usingthe hash of the accepted block 302). The distributed network will alwaysconsider the longest chain of blocks to be the correct one, and willoperate to continue to extend it. If a device receives two differentversions of a block, it will work on the first block received, but savethe second block received in case the branch of the chain that includesthe second block becomes longer (at which point that device will switchto working on the branch of the chain that includes the second block).

Conventionally, the electronic coin(s) 200 and crypto currency publicledger 300 discussed above provide a distributed crypto currency systemin which payers and payees may participate in transactions with eachother using the electronic coins discussed above and without the needfor a centralized authority such as a bank. Each of those transactionsis recorded in the crypto currency public ledger to ensure that theelectronic coins may only be spent by a payer once. It has beendiscovered that the electronic coin(s) 200 and crypto currency publicledger 300 may be utilized in an authentication process that is detailedbelow. However, while discussed mainly in terms of the electroniccoin(s) 200 and crypto currency public ledger 300 detailed above, otherembodiments of the present disclosure envision authentication tokens(which are substantially similar to the electronic coin 200 discussedabove) and an authentication public ledger (which is substantiallysimilar to the crypto currency public ledger 300 discussed above) thatneed not be associated with crypto currencies or the electronic “coins”discussed above. As such, as discussed below, the electronic coin 200may be replaced by a substantially similar authentication token that maybe used to perform authentication transactions on the authenticationpublic ledger that do not necessarily involve the transfer of valuebetween users.

Referring now to FIG. 4, an embodiment of a public ledger authenticationsystem 400 is illustrated and described briefly for reference in themethod 100 discussed below. The public ledger authentication system 400associated with the present disclosure may provide the public ledgerdiscussed below as the crypto currency public ledger 300 discussed abovein FIG. 3 that is part of a crypto currency system, as a dedicatedauthentication public ledger that need not necessarily be associatedwith a crypto currency system, or in other manners that would beapparent to one of skill in the art in possession of the presentdisclosure. For example, one or more system provider devices 402 and/ora public ledger devices 404 coupled together through a network 406 mayoperate to agree on a single history of transactions (e.g., cryptocurrency transactions, authentication transactions, etc.) in a publicledger 408 that may be stored on respective transaction databases 402 aand 404 a that are accessible by those system provider device(s) 402and/or a public ledger device(s) 404 (e.g., each device may store itsown copy of the public ledger). As discussed below, a user device 410connected to the network 406 may then perform registration andauthentication with the system provider device(s) 402.

In a specific example, for a block (e.g., similar to the blocks 302 and304 discussed above with reference to FIG. 3) that includes a pluralityof transaction (e.g., crypto currency transactions, authenticationtransactions, etc.), any of the system provider device(s) 402 and/or thepublic ledger device(s) 404 may increment a nonce in that block until avalue is found that gives a hash of that block the required number ofzero bits. The device may then “chain” that block to the previous block(which may have been “chained” to a previous block in the same manner).When the system provider device(s) 402 and/or the public ledgerdevice(s) 404 find the proof-of-work for a block, that block may bebroadcast to the distributed network (e.g., system provider device(s)402 and/or the public ledger device(s) 404), and that block will beaccepted if all the transactions in it are valid (which may bedetermined by creating the next block using the hash of the acceptedblock). The system provider device(s) 402 and/or the public ledgerdevice(s) 404 will always consider the longest chain of blocks to be thecorrect one, and will operate to continue to extend it. If any of thesystem provider device(s) 402 and/or the public ledger device(s) 404receives two different versions of a block, they will work on the firstblock received, but save the second block received in case the branch ofthe chain that includes the second block becomes longer (at which pointthat device with switch to working on the branch of the chain thatincludes the second block).

As such, in some embodiments, the registration transactions andauthentication attempt transactions performed in the public ledgerauthentication system 400 as discussed herein may be recorded andpublished in the public ledger 408 as part of the crypto currencytransactions performed in a distributed crypto currency system (e.g., aBitcoin system), or in a substantially similar manner in a dedicatedpublic ledger authentication system. As discussed above, in someexamples of those embodiments, the creation and monitoring of the publicledger may be performed by a distributed network of computing systemsoperating to provide a crypto currency system or a dedicated publicledger authentication system. In other embodiments, the creation andmonitoring of the public ledger 408 may be performed by a centralauthority such as the system provider discussed below. As such, thetransactions recorded in the public ledger 408 may not be created andmonitored like a distributed crypto currency, but rather may be recordedand tracked by the system provider device(s) 402 without necessarilyincluding the public keys, signatures, and/or private keys utilized intracking the transactions in a distributed crypto currency system. Assuch, a wide variety of variation in the manner in which transactionsare reported, recorded, and published in the public ledger 408 of thepublic ledger authentication system 400 are envisioned as falling withinthe scope of the present disclosure.

Referring now to FIG. 5, an embodiment of a user device 500 isillustrated that may be the user device 410 discussed above, and whichmay be provided by a desktop computing system, a laptop/notebookcomputing system, a tablet computing system, a mobile phone, and/orother user devices known in the art. In the illustrated embodiment, theuser device 500 includes a chassis 502 that houses the components of theuser device 500, only some of which are illustrated in FIG. 5. Forexample, the chassis 502 may house a processing system (not illustrated)and a non-transitory memory system (not illustrated) that includesinstructions that, when executed by the processing system, cause theprocessing system to provide an application engine 504 for is configuredto perform the functions of the applications and user devices discussedbelow. In a specific example, the application engine 504 is configuredto provide an internet browser application 504 a and the transactionwallet application 504 b discussed below, although one of skill in theart in possession of the present disclosure will recognize that otherapplications and computing device functionality may be enabled by theapplication engine 504 as well. The chassis 502 may also house acommunication system 506 that is coupled to the application engine 504(e.g., via a coupling between the communication system 506 and theprocessing system) and configured to provide for communication throughthe network 406 as detailed below.

In some embodiments, the system provider device(s) 402 may provide thetransaction wallet application 504 b through the network to the userdevice 500 prior to or during the method 100 (e.g., in order to performthe registration sub-method 100A). However, in other embodiments, thetransaction wallet application 504 b may be provided on the user device500 by the user separately from the method 100. For example, thetransaction wallet application 504 b may be utilized with a cryptocurrency system as discussed above to perform crypto currencytransactions. As such, the transaction wallet application 504 b may be adedicated authentication transaction wallet application, a cryptocurrency transaction wallet application that has be “repurposed” for usein public ledger authentication, or other public ledger wallets known inthe art.

Referring now to FIG. 1A, the registration sub-method 100A begins atblock 102 where a system provider device receives and stores useridentification information from a user device. In some embodiments, theregistration sub-method 100A may be performed by a user of the userdevice 410 upon initial registration with the system provided by thesystem provider device(s) 402 (or utilizing the public ledgerauthentication system provided by the system provider device(s) 402).However, in other embodiments, the registration sub-method 100A may beperformed by a user of the user device 410 that has previouslyregistered with the system provided by the system provider devices 402(or utilizing the public ledger authentication system provided by thesystem provider device(s) 402) in order to subsequently authenticatewith that system. At block 102, the user device 410 may provide thesystem provider device(s) 402 a variety of user identificationinformation such as, for example, a name of the user, an address of theuser, a phone number of the user, a date of birth of the user, a socialsecurity number of the user, and/or any other identifier that may beutilized to identify the user. For example, the user identificationinformation may be received via a secure data transfer using a useridentification information web page provided by the system providerdevice(s) 402 through the network 406 to the user device 410. However,in another example, the user identification information may have beenpreviously collected from the user device 410 or via other means by thesystem provider device(s) 402. At block 102, the system providerdevice(s) 402 may store that user identification information in one ormore databases that are accessible to the system provider device(s) 402.

The method 100A may then proceed to block 104 where the system providerdevice generates a first user static key using the user identificationinformation, and stores the first user static key. In an embodiment, atblock 104 the system provider device(s) 402 may use a hash function toperform a hash operation on the user identification information receivedfrom the user and stored at block 102 in order to generate a first userstatic key, and store that first user static key in one or moredatabases that are accessible to the system provider device(s) 402. Asdiscussed below, the hash operation may be performed by the systemprovider device(s) 402 using the hash function that is shared with theuser device 410 so that the user may generate a second static user keyusing their user identification information that is identical to thefirst user static key if that user is an authorized user that both 1)knows the user identification information, and 2) has received thecorrect hash function from the system provider. For example, the systemprovider device(s) 402 may provide or identify the hash function to theuser device 410/500 through the network 406, and the user device 410/500may store that hash function (or the identity/location of that hashfunction) in the transaction wallet application 504 b.

The registration sub-method 100A then proceeds to block 105 where thesystem provider device sends a first registration public ledger addressto the user device. In an embodiment, at block 105 the system providerdevice(s) 402 may send a first registration public ledger addressthrough the network 406 to the user device 410. For example, at block105, the system provider device(s) 402 may identify a “to” address inthe public ledger 408 (i.e., an address in the public ledger 300 that iscontrolled by the system provider device(s) 402) as a first registrationpublic ledger address, and send that first registration public ledgeraddress through the network 406 to the user device 410. In anembodiment, the transmission of the first registration public ledgeraddress may be performed via a secure data transfer. For example, thetransmission of the first registration public ledger address may beperformed by the system provider device(s) 402 over a secure datachannel, the system provider device(s) 402 may encrypt the firstregistration public ledger address before its transmission, and/or avariety of other secure data transfer methods may be performed at block105 to ensure that the first registration public ledger address cannotbe intercepted in a manner that discloses that first registration publicledger address to entities other than the user.

The registration sub-method 100A then proceeds to block 106 where thesystem provider device receives a second registration public ledgeraddress from the user device. In an embodiment, at block 106 the userdevice 410 may send a second registration public ledger address throughthe network 406 to the system provider device(s) 402. For example, atblock 106, the transaction wallet application 504 b in the user device410/500 may identify a “from” address in the public ledger 408 (i.e., anaddress in the public ledger 300 that is associated with electroniccoin(s) 200 and/or authentication tokens that are controlled by thetransaction wallet application 504 b) as a second registration publicledger address, and send that second registration public ledger addressthrough the network 406 to the system provider device(s) 402. In anembodiment, the transmission of the second registration public ledgeraddress may be performed via a secure data transfer. For example, thetransmission of the second registration public ledger address may beperformed by the transaction wallet application 504 b over a secure datachannel, the transaction wallet application 504 b may encrypt the secondregistration public ledger address before its transmission, and/or avariety of other secure data transfer methods may be performed at block106 to ensure that the second registration public ledger address cannotbe intercepted in a manner that discloses that second registrationpublic ledger address to entities other than the system provider.

The registration sub-method 100A then proceeds to block 108 where thesystem provider device retrieves a second user static key sent to thefirst registration public ledger address from the second registrationpublic ledger address in a transaction in the public ledger. In anembodiment, following block 106, the user device 410 may generate thesecond static user key using the hash function (received or identifiedby the system provider device(s) 402) and the user identificationinformation discussed above. The user device 410 may then send thatsecond static user key to the first registration public ledger addressfrom the second registration public ledger address in a transaction inthe public ledger 408. For example, the transaction wallet application504 b in the user device 410/500 may generate the second user static keyas discussed above and include it in a metadata field of a transactionin the public ledger 408 that is sent to the first registration publicledger address from the second registration public ledger address. Insome embodiments, the transaction at block 108 may be a crypto currencytransaction that sends an amount of crypto currency (e.g., 1 satoshi ina Bitcoin transaction that is worth fractions of cent) to the firstregistration public ledger address from the second registration publicledger address, and that includes the second static user key in metadataprovided with the transaction. In other embodiments, the transaction atblock 108 may send an authentication token to the first registrationpublic ledger address from the second registration public ledgeraddress, and that includes the second static user key in metadataprovided with the transaction.

At block 108, the system provider device(s) 402 may retrieve the seconduser static key sent to the first registration public ledger addressfrom the second registration public address in the transaction in thepublic ledger 408 by accessing the public ledger 408 and using the firstand second registration public ledger addresses to identify thetransaction that includes the second static user key in its metadata,and then retrieving the second static user key from that transaction. Inthe event that no static user key is included in the transaction sent tothe first registration public ledger address from the secondregistration public ledger address, the registration sub-method 100A mayend and the user may not be registered with the system. As such, thesecure data transfer of the first and second registration public ledgeraddresses between the user device 410 and the system provider device(s)402 ensures the system provider device(s) 402 that a subsequent staticuser key retrieved in a transaction to the first registration publicledger address and from the second registration public ledger addresswas provided by the user.

The registration sub-method 100A then proceeds to block 110 where thesystem provider device verifies the second static user key using thefirst static user key to provide a verified static user key in thepublic ledger. In an embodiment, the system provider device(s) 402 maycompare the second static user key that was retrieved from the publicledger 408 at block 108 with the first static user key that wasgenerated by the system provider device(s) 402 and stored at block 104to determine whether they match. In the event the second static user keyretrieved from the public ledger 408 at block 108 does not match thefirst static user key generated and stored at block 104, theregistration sub-method 100A may end and the user may not be registeredwith the system. However, if the second static user key retrieved fromthe public ledger 408 at block 108 matches the first static user keygenerated and stored at block 104, the second static user key that isincluded in the transaction in the public ledger 408 becomes a verifiedstatic user key, and the user is now “registered” with the system andthe user may subsequently authenticate using the system as described indetail with reference to the authentication sub-method 100B discussedbelow.

The registration sub-method 100A then proceeds to block 112 where thesystem provider device(s) 402 discard the user identificationinformation and the first user static key. In an embodiment, at block112 the system provider device(s) 402 may erase, overwrite, or otherwisediscard the user identification information and the first static userkey that were stored in the at least one database at blocks 102 and 104.As will be appreciated by one of skill in the art in possession of thepresent disclosure, following verification of the second static user keyin the public ledger 408 to provide the verified static user key, thestorage of the user identification information received at block 102 orthe first static user key generated at block 104 is unnecessary as thesystem provider may perform the actions discussed below with regard tothe authentication sub-method 100B to authenticate the user simply usingthe verified static user key included in the transaction in the publicledger 408. Thus, user identification information such as PersonallyIdentifiable Information (PII) does not need to be stored by the systemprovider device(s) 402, and may only reside with the user (e.g.,memorized by the user, stored in the transaction wallet application 504b, etc.)

Referring now to FIGS. 1B and 6, the method 100 may then proceed to theauthentication sub-method 100B. FIG. 6 illustrates a user device 600,which may be the user devices 410 and/or 500 discussed above, includinga display device 602 displaying an embodiment of an authenticationscreen 604. In the illustrated embodiment, the authentication screen 604includes an Internet browser 606 (e.g., provided by the Internet browserapplication 504 a discussed above with reference to FIG. 5) and atransaction wallet 608 (e.g., provided by the transaction walletapplication 504 b discussed above with reference to FIG. 5.) Forexample, the user may access an authentication web page 610 that isprovided on the Internet browser 606 and that includes a public ledgersign-in option 610 a that the user has previously registered for. Inresponse to the user selecting the public ledger sign-in option 610 a,the transaction wallet 608 may automatically launch such that it isprovided on the authentication screen 604 adjacent the Internet browser606. However, in other embodiments, the actions performed according tothe authentication sub-method 100B discussed below may be performedwithout activation or launching of the Internet browser 606 and/or thetransaction wallet 608. For example, in response to loading theauthentication page 610 on the Internet browser, the transaction wallet608 may operate in the background (e.g., without launching) to performthe actions discussed with reference to the authentication sub-method100B below. In another example, authentication may occur for a systemthat is not displayed in an Internet browser, and thus may occurentirely in the background (e.g., without launching the Internet browser606 or the transaction wallet 608) to perform the actions discussed withreference to the authentication sub-method 100B below. As such, a widevariety of authentication scenarios other than those illustrated willbenefit from the teachings of the present disclosure and thus areenvisioned as falling within its scope.

The authentication sub-method 100B begins at block 114 where the systemprovider device receives a first previous authentication public ledgeraddress and a first current authentication public ledger address fromthe user device. In an embodiment, at block 114 the transaction walletapplication 504 b in the user device 410/500 may retrieve a firstprevious authentication public ledger address that may be the “from”address that was used in a previous authentication attempt with thepublic ledger authentication system 400. For example, the first previousauthentication public ledger address may be the “from” address utilizedby the user to perform the most recent authentication with the publicledger authentication system 400 (e.g., the most recent performance ofthe authentication sub-method 100B prior to the current performance ofthe authentication sub-method 100B). In an embodiment, at block 114, thetransaction wallet application 504 b in the user device 410/500 may alsoidentify a “from” address in the public ledger 408 (i.e., an address inthe public ledger 300 that is associated with electronic coin(s) 200and/or authentication tokens that are controlled by the transactionwallet application 504 b) as a first current public ledger address thatwill be used in the authentication attempt discussed in further detailbelow according to the authentication sub-method 100B.

At block 114, the user device 410/500 may send the first previousauthentication public ledger address and the first currentauthentication public ledger address through the network 406 to thesystem provider device(s) 402. In an embodiment, the transmission of thefirst previous authentication public ledger address and the firstcurrent authentication public ledger address may be performed via asecure data transfer. For example, the transmission of first previousauthentication public ledger address and the first currentauthentication public ledger address may be performed by the transactionwallet application 504 b over a secure data channel, the transactionwallet application 504 b may encrypt the first previous authenticationpublic ledger address and the first current authentication public ledgeraddress before transmission, and/or a variety of other secure datatransfer methods may be performed at block 114 to ensure that the firstprevious authentication public ledger address and the first currentauthentication public ledger address cannot be intercepted in a mannerthat discloses first previous authentication public ledger address andthe first current authentication public ledger address to entities otherthan the system provider.

The authentication sub-method 100B then proceeds to block 116 where thesystem provider device uses the first previous authentication publicledger address to access the verified static user key in the publicledger. In an embodiment, the system provider device(s) 402 may utilizethe first previous authentication public ledger address to identify atleast one other previous authentication public ledger address, and usethat other previous authentication public ledger address to identify theverified static user key in the public ledger 408. For example, thesystem provider device(s) 402 may include a database that associateseach user (including the user of the user device 408) with all of the“from” public ledger addresses that have been utilized by that user inprevious authentication attempts with the public ledger authenticationsystem 400. As such, at block 116, the system provider device(s) 402 mayaccess that database and use the first previous authentication publicledger address to determine the user that previously used that firstprevious authentication public ledger address in a previousauthentication attempt, and then reference the other previousauthentication attempt public ledger addresses (including theregistration public ledger address) to access the transaction in thepublic ledger that was performed during the registration method 100A andthat includes the verified static user key.

Furthermore, the system provider device(s) 402 may store all theprevious “to” addresses used in previous authentication transaction bythe user. For example, each previous “to” address may be associated in adatabase with its corresponding “from” address for each of the previousauthentication transactions performed to authenticate the user, and atblock 116 the system provider device(s) 402 may use the “to” and “from”address pairs to access the verified static user key in the publicledger. As such, the system provider device(s) may provide the userdevice with a different “to” address for each authentication transactionso that each authentication transaction is associated with different“to” and “from” address pairs.

The authentication sub-method 100B then proceeds to block 118 where thesystem provider device provides a second current authentication publicledger address to the user device. In an embodiment, at block 118, thesystem provider device(s) 402 may identify a “to” address in the publicledger 408 (i.e., an address in the public ledger 300 that is associatedwith electronic coin(s) 200 and/or authentication tokens that arecontrolled by the system provider device(s) 402) as a second currentpublic ledger address that will be used in the authentication attemptdiscussed in further detail below, and send that second currentauthentication public ledger address through the network 406 to the userdevice 410. In an embodiment, the transmission of the second currentauthentication public ledger address may be performed via a secure datatransfer. For example, the transmission of the second currentauthentication public ledger address may be performed by the systemprovider device(s) 402 over a secure data channel, the system providerdevice(s) 402 may encrypt the second current public ledger addressbefore transmission, and/or a variety of other secure data transfermethods may be performed at block 118 to ensure that the second currentauthentication public ledger address cannot be intercepted in a mannerthat discloses second current authentication public ledger address toentities other than the user.

The authentication sub-method 100B then proceeds to block 120 where thesystem provider device determines authentication attempt information. Inan embodiment, at block 120 the system provider device(s) 402 determinesauthentication attempt information that may include, for example, anumber of previous authentication attempts by the user. For example,using the first previous authentication public ledger address and thedatabase of other previous authentication public ledger addresses usedby the user in previous authentication attempts, the system providerdevice(s) may determine a count the number of previous authenticationattempts by the user. In addition, in some embodiments theauthentication attempt information may include a date and time for thecurrent authentication attempt. For example, the system providerdevice(s) 402 and the transaction wallet application 504 b in the userdevice 500 may synchronize a date and time between each other, and atblock 120 the system provider device(s) may identify a date and time forthe current authentication attempt by the user.

The authentication sub-method 100B then proceeds to block 122 where thesystem provider device generates a first user authentication key usingthe authentication attempt information and the verified static user key.In an embodiment, at block 122 the system provider device(s) 402 may usea hash function to generate a first user authentication key byperforming a hash operation on the authentication attempt information.For example, the system provider device(s) 402 may utilize a hashfunction (which may be shared with the user device 410 similarly asdiscussed above for the hash function used in the registration method100A) with the verified static user key that was accessed at block 116,along with the number of previously authentication attempts by the user,to generate the first user authentication key. In some specificexamples, the hash operation may be performed on the verified staticuser key, the number of previous authentication attempts by the user,the date and time for the current authentication attempt, and/or otherinformation available to the system provider device(s).

The authentication sub-method 100B then proceeds to block 124 where thesystem provider device retrieves a second user authentication key sentfrom the first current authentication public ledger address to thesecond current authentication public ledger address in a transaction inthe public ledger. In an embodiment, at block 124 the user device maygenerate a second user authentication key using the same hash functionthat was utilized by the system provider device at block 122 to generatethe first user authentication key, and send that second userauthentication key from the first current authentication public ledgeraddress (provided to the system provider device(s) 402 at block 114) tothe second current authentication public ledger address (received fromthe system provider device(s) 402 at block 118) in a transaction on thepublic ledger 408. As such, at block 124 the transaction walletapplication 504 b in the user device 410/500 may perform the same hashoperation as was performed by the system provider device at block 122 onthe verified static user key (which may be stored in the transactionwallet application 504 b or accessible by the user device 410 on thepublic ledger 408), the number of previous access attempts by the user(which may be stored in or accessible by the transaction walletapplication 504 b), and in some examples the date and time of thecurrent authentication attempt (which is synchronized with the systemprovider device(s)) to generate the second user authentication key. Assuch, in some embodiments, the user device 410 may only need to storethe “from” address used in the most recent authentication attempt alongwith a count of the number of authentication attempts to the publicledger authentication system 400 in order to authenticate to a securesystem.

The transaction wallet application 504 b may then provide the seconduser authentication key as metadata in a transaction that is sent fromthe first current authentication public ledger address to the secondcurrent authentication public ledger address in a transaction on thepublic ledger 408. As such, at block 124, the system provider device(s)402 may access that transaction on the public ledger 408 (i.e., byreferencing the first current authentication public ledger addressand/or the second current authentication public ledger address, both ofwhich are known to the system provider device(s) 402) and retrieve thesecond user authentication key.

The authentication sub-method 100B then proceeds to block 126 where thesystem provider device authenticates the user if the second userauthentication key matches the first user authentication key. In anembodiment, if the system provider device(s) 402 determine that thesecond user authentication key retrieved at block 124 matches the firstuser authentication key generated at block 122, the system providerdevice(s) 402 may authenticate the user and allow the user to access thesecure system protected by the public ledger authentication system 400.However, if the system provider device(s) 402 determine that the seconduser authentication key retrieved at block 124 does not match the firstuser authentication key generated at block 122, the system providerdevice(s) does not authenticate the user and the user is not allowed toaccess to the secure system protected by the public ledgerauthentication system 400.

Thus, systems and methods have been described that provide for theauthentication of a user to the system via a public ledger. The publicledger authentication systems and methods provide for registration andauthentication of users using a public ledger in a manner thateliminates the need for the system provider to store user identificationinformation about the user, while only requiring the user to store aprevious “from” address used in an authentication attempt, along withthe number of authentication attempts that have been made to the system.As such, the public ledger authentication system provides a secureauthentication system where the protection of the number ofauthentication attempts and the addresses used in those authenticationattempts prevents unauthorized authentication to the system.

A wide variety of systems may be built on top of the authenticationsystems and methods discussed above to leverage the ability to verifyand authenticate users via a public ledger as discussed above. Forexample, as discussed below, modifications to the authenticationsub-method 100A discussed above allow for the linking of a “real”identity of a user (e.g., a name, address, phone number, social securitynumber, financial account number, payment account information, and/orother user identity information) with a verified user static key in apublic ledger. That linking of the “real” identity to the verified userstatic key may be leveraged to provide anonymous payments in which apayer can transfer funds to a payee, while the payee may be ensured thatthe payer has been verified according to a variety of complianceregulations (e.g., Know Your Customer (KYC) regulations, Anti-MoneyLaundering (AML) regulations, etc.) and thus that the funds from thepayer are safe and/or legal to accept. While in the embodimentsdiscussed below, the systems and methods are described as providing foranonymous donations from a donor user to a donee user, one of skill inthe art in possession of the present disclosure will recognize that theteachings herein may be applied to variety of anonymous payments or fundtransfers while remaining within the scope of the present disclosure.

Referring now to FIG. 7, an embodiment of an anonymous payment system700 is illustrated and described briefly for reference in the anonymousdonation/payment method 800 discussed below. The anonymous paymentsystem 700 includes similar components to the public ledgerauthentication system 400 described above with reference to FIG. 4, andthus those similar components are provided with similar referencenumbers. As such, the anonymous payment system 700 may provide thepublic ledger discussed herein that is part of a virtual orcrypto-currency system, as a dedicated authentication public ledger thatneed not necessarily be associated with a virtual or crypto-currencysystem, or in other manners that would be apparent to one of skill inthe art in possession of the present disclosure. Similarly as discussedabove, the one or more system provider devices 402 and/or public ledgerdevice(s) 404 coupled together through the network 406 may operate toagree on a single history of transactions (e.g., crypto-currencytransactions, authentication transactions, etc.) in the public ledger408 that may be stored on the respective transaction databases 402 a and404 a that are accessible by those system provider device(s) 402 and/orpublic ledger device(s) 404 (e.g., each device may store its own copy ofthe public ledger). As discussed below, a payer device (illustrated asthe donor device 702 in FIG. 7) and a payee device (illustrated as thedonee device 704 in FIG. 7) are connected to the network 406 and mayperform registration and authentication with the system providerdevice(s) 402 as discussed above, as well as the anonymouspayment/donation functionality discussed below.

With reference back to FIG. 1A and the registration sub-method 100A, insome embodiments, blocks 102, 104, 105, 106, 108, and 110 of theregistration sub-method 100A may be performed while block 112 may bemodified. For example, rather than discard the user identificationinformation as discussed above for original block 112, the systemprovider device(s) 402 may perform a modified block 112 and operate tostore the user identification information received at block 102 in adatabase (e.g., similar to the transaction database 402 a) inassociation with the verified user static key that was provided in thepublic ledger at block 110. As such, user identity information of usersincluding user names, user addresses, user phone numbers, user socialsecurity numbers, user financial account numbers, user payment accountinformation (e.g., payment account access information), and/or otheruser identity information known in the art, may be associated in adatabase that is accessible by the system provider device(s) 402 withthe verified user static keys that were created for those users duringthe registration sub-method 100A and stored in the public ledger.

In some embodiments of the modified block 112 discussed above, thesystem provider device(s) 402 may operate to perform a regulationverification process such as a KYC process to verify the identity of theuser (e.g., using the user identification information). As is known inthe art, KYC processes may be performed to ensure that money handlingsystems are not used by criminal elements for money launderingactivities, and may include any or all of: collection and analysis ofthe user identification information (referred to in the United Statesregulations and practice as a “Customer Identification Program” or CIP);user name matching against lists of known parties (such as “politicallyexposed person” or PEP); determination of the customer's risk in termsof propensity to commit money laundering, terrorist finance, or identitytheft; creation of an expectation of a customer's transactional behavior(e.g., using access to user payment or financial accounts provided viathe user identification information); and monitoring of a customer'stransactions against expected behavior and recorded profile as well asthat of the customer's peers (e.g., using access to user payment orfinancial accounts provided via the user identification information).Furthermore, in some embodiments, the system provider may not performthe regulation verification process, but rather may communicate with athird party that has done so in order to regulation verify a user. Forexample, some donor users may be verified or pre-verified (e.g., priorto requesting a donation to a donee) by a third party system and thesystem provider may confirm that regulation verification rather withthat third party system rather than perform the regulation verificationprocess.

Thus, following modified block 112 of the registration sub-method 100A,the system provider device(s) 402 may include a verified user databasethat includes “verified” users (e.g., user's that have been verifiedusing their user identification information according to KYC or similarregulations) associated with respective verified user static keys thatare stored in the public ledger. In some embodiments, block 112 may bemodified in a variety of manners other than those discussed above. Forexample, the user identification information for any user may be storedin association with the verified user static key for that user, and thensubject to the verification process when a payment or donation isrequested by that user. In another example, the user identificationinformation for any user may be used to perform the verification processfor that user as discussed above, and following the verificationprocess, that user identification information may be discarded while theresults of that verification process may be stored in association withthe verified user static key. As such, a verified user static key may beassociated with a regulation verified user indication (i.e., a KYCcompliant user indication) while the user identification informationused to determine that the user is regulation verified has beendiscarded, and a verified user static key may be associated with aregulation non-verified user indication (i.e., a non-KYC compliant userindication) while the user identification information used to determinethat the user is not regulation verified has been discarded.

Referring now to FIG. 8, an embodiment of an anonymous payment/donationmethod 800 is illustrated. Making payments such as, for example, thedonations discussed below, can subject the payer/donor to subsequentcommunications (e.g., “spam” communications) from any parties thatreceive and/or intercept their user identity information along with thatpayment/donation. In addition, some payers/donors may not want topublicize their generosity. To avoid such communication and/orpublicity, many prospective donors may avoid making donations. Onesolution to this problem is for donors to make such donationsanonymously. However, anonymous donations raise a number of issues. Forexample, many businesses, companies, and/or entities may be hesitant toaccept payments and/or donations from an anonymous payer/donor, asregulatory compliance rules require that the identity of suchpayers/donors be known to ensure that those payments/donations are notbeing made by criminal elements for money laundering activities. Theanonymous payment/donation method 800 discussed below utilizes amodified form of the registration sub-method 100A and authenticationsub-method 100B discussed above to provide for anonymouspayments/donations from a payer/donor to a payee/donee, while providingassurances to the payee/donee that the payer/donor satisfies anyapplicable regulatory compliance rules.

The anonymous donation method begins at block 802 where a systemprovider device receives donor identity information and verifies thedonor identity information. In an embodiment of block 802, a donor userof the donor device 702 may send donor identity information to thesystem provider device(s) 402 through the network 406, and the systemprovider device(s) 402 may receive that donor identity information andoperate to verify the donor identity information. As discussed above,the donor user of the donor device 702 may operate in conjunction withthe system provider and the system provider device(s) 402 according tothe registration sub-method 100A such that the donor user uses the donordevice 702 to provide donor user identification information to thesystem provider device(s) 402 at block 102; the system providerdevice(s) 702 generate a first donor user static key using the donoruser identification information, and store the first donor user statickey at block 104; the system provider device(s) 702 send the firstregistration public ledger address to the donor device 702 at block 105;the system provider device(s) 402 receive the second registration publicledger address from the donor device 702 at block 106; the systemprovider device(s) 402 retrieve a second donor user static key sent fromthe first registration public ledger address to the second registrationpublic ledger address in a transaction in a public ledger at block 108;and the system provider device(s) 402 verify the second donor userstatic key using the first donor user static key to provide the verifieddonor user static key in the public ledger at block 110; allsubstantially as discussed above with regard to the registrationsub-method 100A.

Furthermore, at block 802, the system provider device(s) 402 may thenoperate according to the modified block 112 of the registrationsub-method 100A discussed above to associate the verified donor userstatic key with the donor user identification information received fromthe donor user via the donor device 702. As discussed above, this mayinvolve applying a variety of regulatory compliance rules to the donoruser identification information (e.g., KYC compliance rules), confirminga regulation verification of the donor user, and/or performing a varietyof other actions on that donor user identification information that oneof skill in the art in possession of the present disclosure wouldrecognize would provide a verified donor user according to the teachingsof the present disclosure Furthermore, as discussed in the exampleabove, the donor user identification information for the donor user maybe stored in association with the verified user static key for the donoruser in a database of the system provider device(s) 402, and thensubject to the verification processes discusses above when a payment ordonation is requested by the donor user at block 806. Further still, asdiscussed in another of the examples above, the donor useridentification information for the donor user may be used by the systemprovider device(s) 402 to perform the verification processes discussedabove, and following the verification processes that donor useridentification information may be discarded by the system providerdevice(s) 402 while the results of that verification process (e.g., aregulation-verification indicator) may be stored in association with theverified user static key for the donor user in a database of the systemprovider device(s) 402. As such, a verified user static key may beassociated with a regulation verified donor user indicator (i.e., a KYCcompliant donor user indicator) while the donor user identificationinformation for the donor user has been discarded. Similarly, a verifieduser static key may be associated with a regulation non-verified donoruser indication (i.e., a non-KYC compliant donor user indication) whilethe user identification information for that donor user has beendiscarded.

The method 800 then proceeds to block 804 where the system providerdevice receives donee identity information and verifies the doneeidentity information. In an embodiment of block 802, a donee user of thedonee device 704 may send donee user identity information to the systemprovider device(s) 402 through the network 406, and the system providerdevice(s) 402 may receive that donee user identity information andoperate to verify the donee user identity information. As discussedabove, the donee user of the donee device 702 may operate in conjunctionwith the system provider device(s) 402 according to the registrationsub-method 100A such that the donee user uses the donee device 702 toprovide donee user identification information to the system providerdevice(s) 402 at block 102; the system provider device(s) 702 generate afirst donee user static key using the donee user identificationinformation, and store the first donee user static key at block 104; thesystem provider device(s) 702 send the first registration public ledgeraddress to the donee device 702 at block 105; the system providerdevice(s) 402 receive the second registration public ledger address fromthe donee device 702 at block 106; the system provider device(s) 402retrieve a second donee user static key sent from the first registrationpublic ledger address to the second registration public ledger addressin a transaction in the public ledger at block 108; and the systemprovider device(s) 402 verify the second donee user static key using thefirst donee user static key to provide the verified donee user statickey in the public ledger at block 110; all substantially as discussedabove with regard to the registration sub-method 100A.

Furthermore, at block 802, the system provider device(s) 402 may thenoperate according to the modified block 112 of the registrationsub-method 100A discussed above to associate the verified donee userstatic key with the donee user identification information for the doneeuser. As discussed above, this may involve applying a variety ofregulatory compliance rules to the donee user identification information(e.g., KYC compliance rules), confirming the status of the donee user asa 501(3)(c) entity via the Federal Charity Registry, checking charityrating websites such as Charity Navigator (www.charitynavigator.org),and/or performing a variety of other actions on the donee useridentification information that one of skill in the art in possession ofthe present disclosure would recognize would provide a verified doneeuser according to the teachings of the present disclosure. Furthermore,as discussed in the example above, the donee user identificationinformation for the donee user may be stored in association with theverified user static key for the donee user in a database of the systemprovider device(s) 402, and then subject to the verification processesdiscussed above when a payment or donation is requested by the doneeuser at block 806. Further still, as discussed in another of theexamples above, the donee user identification information for the doneeuser may be used to perform the verification processes discussed above,and following the verification process that donee user identificationinformation may be discarded by the system provider device(s) 402 whilethe results of that verification process may be stored in associationwith the verified user static key for the donee user in a database ofthe system provider device(s) 402. As such, a verified user static keymay be associated with a regulation verified donee user indication(i.e., a KYC compliant donee user indication) while the donee useridentification information for the regulation verified donee user hasbeen discarded. Similarly, a verified user static key may be associatedwith a regulation non-verified donee user indication (i.e., a non-KYCcompliant donee user indication) while the user identificationinformation for that regulation non-verified donee user has beendiscarded by the system provider deivce(s) 402.

One of skill in the art in possession of the present disclosure willappreciate that, in some embodiments, block 804 of the method 800 may beskipped. For example, in many situations, the regulation verification ofthe donee user may be unnecessary, as the concern associated with thedonation to the donee user is the regulation verification of the donoruser. As such, in many embodiments of the method 800, the verificationof the donee user may not be necessary (despite its performance or notat block 804) because the verification of that donee user is not used inthe method 800. However, in some embodiments, the regulationverification of the donee user may be important to the donor user (i.e.,to ensure that the donation is being provided to a KYC compliant doneeuser), and thus the verification of the donee user identificationinformation may be performed at block 804 and utilized in the method 800to, for example, verify to the donor user that the donee user is aregulation verified donee user (which may be performed in substantiallythe same manner as discussed below for verifying to the donee user thatthe donor user is a regulation verified donor user).

The method 800 then proceeds to block 806 where the donor device createsa multi-signature transaction that is directed to the donee and thatincludes the system provider as a signing party. In an embodiment, thedonor user uses the donee device 702 to create a multi-signaturecrypto-currency transaction that is directed to the donee user and thatincludes the system provider as a signing party. One of skill in the artin possession of the present disclosure will recognize that the donoruser may initiate a donation to the donee user by creating themulti-signature crypto-currency transaction that identifies an amount offunds to transfer, identifies the donee as the destination of the funds,and includes the system provider as a signing party. For example, themulti-signature crypto-currency transaction created at block 806 mayrequire signatures using both of a private key available to the donoruser and a private key available to the system provider in order forthat crypto-currency transaction to transfer the identified funds fromthe donor user to the donee user. As such, the donor device 702 and/orthe system provider device(s) 420 may gather (or generate) public ledgeraddresses on the donor device 702 and the system provider device(s) 402,obtain public keys from the donor device 702 and the system providerdevice(s) 402, and create a multi-signature crypto-currency transactionaddress for the multi-signature crypto-currency transaction. At block806, the donor user may then create a crypto-currency transaction thatidentifies the donee user as a destination of funds, and send thattransaction to the multi-signature crypto-currency transaction address.As discussed below, the multi-signature crypto-currency transaction maybe used to verify the donor user at block 808. In some embodiment, amulti-signature crypto-currency transaction created for a first donationmay then be used for verification of the donor user in a subsequent,second donation when, for example, the state of the donor user does notchange and local regulations allow. However, in other embodiments a newmulti-signature crypto-currency transaction may be created for eachdonation.

While the multi-signature crypto-currency transaction is discussed aboveas identifying an amount of donation funds for the donee user, in someembodiments, the multi-signature crypto-currency transaction may notidentify the amount of donation funds for the donee user, and the amountof donation funds for the donee user may be provided by the donor userto the system provider device(s) 402 separately. For example, thedonation by the donor user may be identified separately from themulti-signature crypto-currency transaction through a payment websiteprovided by the system provider device(s) 402. In such embodiments, themulti-signature crypto-currency transaction may include a nominal amountof crypto-currency for transfer (e.g., 0.00000001 Bitcoins), and may beutilized below for the verification of the donor user rather than thetransfer of funds from the donor user to the donee user.

The method 800 then proceeds to block 808 where the system providerdevice identifies the multi-signature transaction, verifies the identityof the donee, and signs the multi-signature transaction. In anembodiment, at block 808 the system provider device(s) 402 identify themulti-signature crypto-currency transaction created by the donor deviceat block 806. For example, the system provider device(s) 402 mayidentify the multi-signature crypto-currency transaction in responseaccessing a public ledger and determining that the donor device 702 hassent a transaction to a multi-signature crypto-currency transactionaddress that was created using a public ledger address and a public keyof the system provider. Furthermore, the identification of themulti-signature crypto-currency transaction may include identifying apublic ledger address of the donee user that was used (along with apublic key of the donee) to create the multi-signature crypto-currencytransaction address.

Block 808 may then proceed where the system provider device(s) 402verify the identity of the donor user. In an embodiment, at block 808the system provider device(s) 402 may operate according to portions ofthe authentication sub-method 100B discussed above to verify theidentity of the donor user. For example, with reference to theauthentication sub-method 100B in FIG. 1B, at block 114 the systemprovider device(s) 402 may determine the public ledger address of thedonor user that was used to create the multi-signature crypto-currencytransaction address (i.e., the first previous authentication publicledger address with reference to block 114 of the authenticationsub-method 100B), along with the first current authentication publicledger address from the donor user device 702. The system providerdevice(s) 402 may then use the public ledger address of the donor userthat was used to create the multi-signature crypto-currency transactionaddress (i.e., the first previous authentication public ledger addresswith reference to block 116 of the authentication sub-method 100B) toaccess the verified user static key for the donor user in the publicledger at block 116. Similarly as discussed above, then system providerdevice(s) 402 may then provide the second current authentication publicledger address to the donor user device 702 at block 118, determineauthentication attempt information at block 120, generate the firstdonor use authentication key using the authentication attemptinformation and the verified user static key of the donor user at block122, retrieve a second user authentication key sent from the firstcurrent authentication public ledger address to the second currentauthentication public ledger address in a transaction on the publicledger at block 124, and verify the donor user if the second userauthentication key matches the first user authentication key.

If the second user authentication key matches the first userauthentication key according to the authentication sub-method 100B asdiscussed above, the system provider device(s) 402 confirms that themulti-signature crypto-currency transaction identified at block 808 isassociated with the verified user static key. Furthermore, as discussedabove, that verified user static key may have been previously associatedwith donor user identification information and/or a regulation verifieddonor user indication, and thus the system provider device(s) 402 mayconfirm whether the donor user that created the multi-signaturecrypto-currency transaction is a regulation verified user (e.g., a KYCregulation compliant user).

If the system provider device(s) 402 determine that the donor user is aregulation verified user, block 808 may proceed with the system providerdevice signing the multi-signature crypto-currency transaction. Forexample, the system provider device(s) may include rules (e.g., defaultrules, rules provided by the donee user, etc.) that indicate that themulti-signature crypto-currency transaction should be signed when thedonor user is a regulation verified user. If the system providerdevice(s) 402 determine that the donor user is not a regulation verifieduser, block 808 may proceed with the system provider device not signingthe multi-signature crypto-currency transaction. For example, the systemprovider device(s) may include rules (e.g., default rules, rulesprovided by the donee user, etc.) that indicate that the multi-signaturecrypto-currency transaction should not be signed when the donor user isa not a regulation verified user. However, in some embodiments, thedetermination that the donor use is not a regulation verified user maystill result in the system provider device(s) 402 signing themulti-signature crypto-currency transaction. For example, the systemprovider device(s) 402 may determine that the donor user is not aregulation verified user, sign the multi-signature crypto-currencytransaction, and then inform the donee user (as discussed below in block810) that the donor user is a not a regulation verified user.

The method 800 then proceeds to block 810 where the system providerdevice transfers funds from the donor to the donee and sends anotification to the donee device. In an embodiment, subsequent to theverification of the identity of the donor user, the system providerdevice(s) 402 may perform operations to cause the transfer of funds fromthe donor user to the donee user. In one example, the signing of themulti-signature crypto-currency transaction by the system providercauses the transfer of funds associated with an address on the publicledger that is controlled (e.g., via a private key) by the donor user toan address on the public ledger that is controller (e.g., via a privatekey) by the donee user. As such, in some embodiments, themulti-signature crypto-currency transaction is configured, in additionto allowing the verification of the donor user, to transfer funds inresponse to being signed by each of the donor user and the systemprovider. However, in other examples, at block 810 the system providerdevice(s) 402 may operate to transfer funds from a donor user account ofthe donor user (e.g., provided by the system provider and/or a paymentprovider) to a donee user account of the donee user (e.g., provided bythe system provider and/or a payment provider) separate from the signingof the multi-signature crypto-currency transaction. As such, themulti-signature crypto-currency transaction signed by the donor user andthe system provider may be for a nominal amount (e.g., 0.00000001Bitcoins), and may primarily be used for the verification of the donoruser, while the donation specified by the donor user (e.g., via apayment account) may be realized via a separate fund transfer betweenaccounts provided to the donor user and the donee user.

Furthermore, at block 810, the system provider device(s) 402 may operateto send a notification to the donee device 704. In an embodiment, atblock 810, the system provider device 402 may generate a notificationabout the fund transfer from the donor user to the donee user and sendthat notification to the donee user via the donee device 704 (e.g., inan email, as an application notification, via conventional mail, etc.).For example, the notification send by the system provider device(s) 402to the donee device 704 at block 810 may identify the amount of thedonation from the donor user to the donee user, an indication of whetherthe donor user has been regulation verified, and/or any of a variety ofother information other than donor user identification information thatwould be relevant to the donee user. As discussed above, some doneeusers may have specified that they will only accept donations fromregulation verified donor users and thus the system provider device(s)402 may only transfer the funds from the donor user to the donee userand send a notification of transferred funds when those funds aretransferred from a regulation verified user at blocks 808 and 810. Insome embodiments, notifications at block 810 may include a notificationsent from the system provider device(s) 402 to a regulatory agencydevice operated by the regulatory agency. As such, funds may betransferred from a donor user to a donee user anonymously in that thedonee user does not have access to donor user identification informationabout the donor user, and the system provider prevents any donor useridentification information from being released with the transfer offunds as per the donation.

The method 800 may then proceed to optional block 812 where the doneedevice verifies the system provider device using an address in themulti-signature transaction. In some embodiments, the system providerdevice(s) 402 and the donee device 704 may have previously utilized theregistration sub-method 100A to allow the donee user to verify theidentity of the system provider. As such, with reference to theregistration sub-method 100A, the donee device 704 may have previouslyreceived system provider identity information and verified the systemprovider identity information at block 102; generated a first systemprovider static key using the system provider identification, and storedthe first system provider static key at block 104; sent the firstregistration public ledger address to the system provider device(s) 402at block 105; received the second registration public ledger addressfrom the system provider device(s) 402 at block 106; retrieved a secondsystem provider static key sent from the first registration publicledger address to the second registration public ledger address in atransaction in the public ledger at block 108; and verified the secondsystem provider static key using the first system provider static key toprovide the verified system provider static key in the public ledger atblock 110; all substantially as discussed above with regard to theregistration sub-method 100A. Furthermore, at optional block 812, thedonee device 704 may have operated according to a modified block 112 ofthe registration sub-method 100A to associate the verified systemprovider static key with the system provider identification informationfor the system provider.

Thus, at optional block 812, the donee device 704 may then operateaccording to the authentication sub-method 100B to verify the systemprovider using the address in the multi-signature crypto-currencytransaction. In an embodiment, at optional block 812, the donee device704 identifies the multi-signature crypto-currency transaction signed bythe donor device 702 and the system provider device(s) 402. For example,the identification of the multi-signature crypto-currency transactionmay include identifying a public ledger address of the system providerthat was used (along with a public key of the system provider) to createthe multi-signature crypto-currency transaction address of themulti-signature crypto-currency transaction that is included in thepublic ledger.

Optional block 812 may then proceed where the donee device 704 verifiesthe identity of the system provider. In an embodiment, at optional block812, the donee device 704 may operate according to portions of theauthentication sub-method 100B to verify the identity of the systemprovider. For example, with reference to the authentication sub-method100B in FIG. 1B, at block 114 the donee device 704 may determine thepublic ledger address of the system provider that was used to create themulti-signature crypto-currency transaction address (i.e., the firstprevious authentication public ledger address with reference to block114 of the authentication sub-method 100B), along with the first currentauthentication public ledger address from the system provider device(s)402. The donee device 704 may then use the public ledger address of thesystem provider that was used to create the multi-signaturecrypto-currency transaction address (i.e., the first previousauthentication public ledger address with reference to block 116 of theauthentication sub-method 100B) to access the verified system providerstatic key for the system provider in the public ledger at block 116.Similarly as discussed above, then donee device 704 may then provide thesecond current authentication public ledger address to the systemprovider device(s) 402 at block 118; determine authentication attemptinformation at block 120; generate the first system providerauthentication key using the authentication attempt information and theverified system provider static key of the system provider at block 122;retrieve a second system provider authentication key sent from the firstcurrent authentication public ledger address to the second currentauthentication public ledger address in a transaction on the publicledger at block 124; and verify the system provider if the second systemprovider authentication key matches the first system providerauthentication key.

If the second system provider authentication key matches the firstsystem provider authentication key according to the authenticationsub-method 100B as discussed above, the donee device 704 confirms thatthe multi-signature crypto-currency transaction identified at optionalblock 812 is associated with the verified system provider static key.Furthermore, as discussed above, that verified system provider statickey may have been previously associated with system provideridentification information, and thus the donee device 702 may confirmthat the system provider is a trusted party.

If the donee device 704 determines that the system provider is a trustedparty, optional block 812 may proceed with the donee user accepting thedonation (i.e., the funds transferred by the system provider from thedonor user to the donee user.) However, in some embodiments, thedetermination that the system provider is not a trusted party may resultin the donee user rejecting the donation, or in some cases requestingthat the system provider perform the registration sub-method 100A inorder to become a trusted party.

In some embodiments, the system provider device(s) 402 may provide thedonee device 704 an anonymous donor user tracking number that does notinclude identification information about the donor user. For example,anonymous donor user tracking numbers may be provided for trackingpurposes by the donee, and may include indications of whether the doneeis allowed to provide subsequent communications to the donor user. Inspecific examples, that anonymous donor tracking number may be utilizedby the donee user with subsequent communications sent to the systemprovider device(s) 402, and the system provider device(s) 402 mayforward those communications to the donor user using the anonymous donoruser tracking number (i.e., based on a link between the anonymous donortracking number and the “real” identity of the donor user).

Thus, a donor/payer users are enabled to make anonymousdonations/payments to donee/payee users via a system provider, and thedonee/payee users may accept the donations/payments with the assuranceof the system provider that the donor/payer is a regulation verifieduser. The verifications of parties in the system, as well as thedonations/payments in many embodiments, may be enabled via a publicledger such as, for example, the Bitcoin Blockchain, and the systemprovider may act as a trusted party that operate to regulation-verifydonor users (e.g., ensure that the donor users are KYC regulationcompliant) and ensure the donee users of that regulation verificationwhen anonymously transferring donations/payments from the donor user tothe donee user. One of skill in the art in possession of the presentdisclosure will recognize that providing donors/payers the ability todonate/pay anonymously while ensuring donees/payees that thedonation/payment is from a regulation verified party may lead to moredonations/payments that can increase funds available to charities, aswell as increase the use of payment networks relative to to those thatprovide conventional donation/payment functionality.

One of skill in the art in possession of the present disclosure willrecognize that a variety of modifications to the systems and methodsdiscussed above with fall within the scope of the present disclosure. Insome embodiments, the method 800 may begin with the donee usersoliciting donations from anonymous donors via the system provider. Forexample, the donee user may begin a donation campaign via a websiteprovided by the system provider (e.g., by specifying the donation cause,suggested donations amounts, etc.), and the system provider may act asan intermediary to receive anonymous donations from the donor users andprovide them to the donee user via the systems and methods discussedabove. In some embodiments, donor users may provide the system providerpreferences and/or profiles that indicate which donation solicitationsthey would like to receive from donee users via the system provider.

Furthermore, some embodiments may involve the system provider verifiesthe identity of donor/donee matching services, which allows donor usersto be matched with donee users while both the donor users and doneeusers remain anonymous to each other (but the donor user and donor/doneematching service will be known to each other.) In such situations, thesystem provider may report the donor/donee matching service, the donor,the donee, and information associated with the donor/donee matching, toregulatory systems as required by local laws.

Referring now to FIG. 7, an embodiment of a networked system 700 used inthe public ledger authentication system 400 described above isillustrated. The networked system 700 includes a plurality of userdevices 702, a plurality of public ledger devices 704, and a pluralityof system provider devices 706 in communication over a network 708. Anyof the user devices 702 may be the user devices operated by the users,discussed above. Any of the public ledger devices 704 may be the publicledgers devices discussed above. Any of the system provider devices 706may be the system provider devices operated by the system providers,discussed above.

The user devices 702, public ledger devices 704, and/or system providerdevices 706 may each include one or more processors, memories, and otherappropriate components for executing instructions such as program codeand/or data stored on one or more computer readable mediums to implementthe various applications, data, and steps described herein. For example,such instructions may be stored in one or more computer readable mediumssuch as memories or data storage devices internal and/or external tovarious components of the system 700, and/or accessible over the network708.

The network 708 may be implemented as a single network or a combinationof multiple networks. For example, in various embodiments, the network708 may include the Internet and/or one or more intranets, landlinenetworks, wireless networks, and/or other appropriate types of networks.

The user devices 702 may be implemented using any appropriatecombination of hardware and/or software configured for wired and/orwireless communication over network 708. For example, in one embodiment,the user devices 702 may be implemented as a personal computer of a userin communication with the Internet. In other embodiments, the userdevices 702 may be a smart phone, wearable computing device, laptopcomputer, and/or other types of computing devices.

The user devices 702 may include one or more browser applications whichmay be used, for example, to provide a convenient interface to permitthe payer to browse information available over the network 708. Forexample, in one embodiment, the browser application may be implementedas a web browser configured to view information available over theInternet.

The user devices 702 may also include one or more toolbar applicationswhich may be used, for example, to provide user-side processing forperforming desired tasks in response to operations selected by the USER.In one embodiment, the toolbar application may display a user interfacein connection with the browser application.

The user devices 702 may further include other applications as may bedesired in particular embodiments to provide desired features to theuser devices 702. In particular, the other applications may include apayment application for payments assisted by a payment service provider.The other applications may also include security applications forimplementing user-side security features, programmatic user applicationsfor interfacing with appropriate application programming interfaces(APIs) over the network 708, or other types of applications. Emailand/or text applications may also be included, which allow the user tosend and receive emails and/or text messages through the network 708.The user devices 702 include one or more user and/or device identifierswhich may be implemented, for example, as operating system registryentries, cookies associated with the browser application, identifiersassociated with hardware of the user devices 702, or other appropriateidentifiers, such as a phone number. In one embodiment, the useridentifier may be used to associate the user with a particular accountas further described herein.

Referring now to FIG. 8, an embodiment of a user device 800 isillustrated. The device 800 may be any of the user devices discussedabove. The device 800 includes a chassis 802 having a display 804 and aninput device including the display 804 and a plurality of input buttons806. One of skill in the art will recognize that the device 800 is aportable or mobile phone including a touch screen input device and aplurality of input buttons that allow the functionality discussed abovewith reference to the method 100. However, a variety of otherportable/mobile devices and/or desktop devices may be used in the method100 without departing from the scope of the present disclosure.

Referring now to FIG. 9, an embodiment of a computer system 900 suitablefor implementing, for example, the user devices, public ledger devices,and/or system provider devices, is illustrated. It should be appreciatedthat other devices utilized in the public ledger authentication systemdiscussed above may be implemented as the computer system 900 in amanner as follows.

In accordance with various embodiments of the present disclosure,computer system 900, such as a computer and/or a network server,includes a bus 902 or other communication mechanism for communicatinginformation, which interconnects subsystems and components, such as aprocessing component 904 (e.g., processor, micro-controller, digitalsignal processor (DSP), etc.), a system memory component 906 (e.g.,RAM), a static storage component 908 (e.g., ROM), a disk drive component910 (e.g., magnetic or optical), a network interface component 912(e.g., modem or Ethernet card), a display component 914 (e.g., CRT orLCD), an input component 918 (e.g., keyboard, keypad, or virtualkeyboard), a cursor control component 920 (e.g., mouse, pointer, ortrackball), and/or a location determination component 922 (e.g., aGlobal Positioning System (GPS) device as illustrated, a cell towertriangulation device, and/or a variety of other location determinationdevices known in the art). In one implementation, the disk drivecomponent 910 may comprise a database having one or more disk drivecomponents.

In accordance with embodiments of the present disclosure, the computersystem 900 performs specific operations by the processor 904 executingone or more sequences of instructions contained in the memory component906, such as described herein with respect to the payer devices, payeedevices, user devices, payment service provider devices, and/or systemprovider devices. Such instructions may be read into the system memorycomponent 906 from another computer readable medium, such as the staticstorage component 908 or the disk drive component 910. In otherembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the presentdisclosure.

Logic may be encoded in a computer readable medium, which may refer toany medium that participates in providing instructions to the processor904 for execution. Such a medium may take many forms, including but notlimited to, non-volatile media, volatile media, and transmission media.In one embodiment, the computer readable medium is non-transitory. Invarious implementations, non-volatile media includes optical or magneticdisks, such as the disk drive component 910, volatile media includesdynamic memory, such as the system memory component 906, andtransmission media includes coaxial cables, copper wire, and fiberoptics, including wires that comprise the bus 902. In one example,transmission media may take the form of acoustic or light waves, such asthose generated during radio wave and infrared data communications.

Some common forms of computer readable media includes, for example,floppy disk, flexible disk, hard disk, magnetic tape, any other magneticmedium, CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, RAM, PROM, EPROM,FLASH-EPROM, any other memory chip or cartridge, carrier wave, or anyother medium from which a computer is adapted to read. In oneembodiment, the computer readable media is non-transitory.

In various embodiments of the present disclosure, execution ofinstruction sequences to practice the present disclosure may beperformed by the computer system 900. In various other embodiments ofthe present disclosure, a plurality of the computer systems 900 coupledby a communication link 924 to the network 708 (e.g., such as a LAN,WLAN, PTSN, and/or various other wired or wireless networks, includingtelecommunications, mobile, and cellular phone networks) may performinstruction sequences to practice the present disclosure in coordinationwith one another.

The computer system 900 may transmit and receive messages, data,information and instructions, including one or more programs (i.e.,application code) through the communication link 924 and the networkinterface component 912. The network interface component 912 may includean antenna, either separate or integrated, to enable transmission andreception via the communication link 924. Received program code may beexecuted by processor 904 as received and/or stored in disk drivecomponent 910 or some other non-volatile storage component forexecution.

Referring now to FIG. 10, an embodiment of a system provider device 1000is illustrated. In an embodiment, the device 1000 may be any of thesystem provider devices discussed above. The device 1000 includes acommunication engine 1002 that is coupled to the network 708 and to anauthentication engine 1004 that is coupled to an authentication database1006. The communication engine 1002 may be software or instructionsstored on a computer-readable medium that allows the device 1000 to sendand receive information over the network 708. The authentication engine1004 may be software or instructions stored on a computer-readablemedium that is configured to perform the registration, authentication,and/or any of the other functionality that is discussed above. While theauthentication database 1006 has been illustrated as a single databaselocated in the device 1000, one of skill in the art will recognize thatit may include multiple databases and be connected to the authenticationengine 1004 through the network 708 without departing from the scope ofthe present disclosure.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the scope of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa.

Software, in accordance with the present disclosure, such as programcode and/or data, may be stored on one or more computer readablemediums. It is also contemplated that software identified herein may beimplemented using one or more general purpose or specific purposecomputers and/or computer systems, networked and/or otherwise. Whereapplicable, the ordering of various steps described herein may bechanged, combined into composite steps, and/or separated into sub-stepsto provide features described herein.

The foregoing disclosure is not intended to limit the present disclosureto the precise forms or particular fields of use disclosed. As such, itis contemplated that various alternate embodiments and/or modificationsto the present disclosure, whether explicitly described or impliedherein, are possible in light of the disclosure. Having thus describedembodiments of the present disclosure, persons of ordinary skill in theart will recognize that changes may be made in form and detail withoutdeparting from the scope of the present disclosure. Thus, the presentdisclosure is limited only by the claims.

What is claimed is:
 1. An anonymous donation system, comprising: anon-transitory memory; and one or more hardware processors coupled tothe non-transitory memory and configured to read instructions from thenon-transitory memory to cause the system to perform operationscomprising: identifying, through a network, a multi-signaturecrypto-currency transaction that is provided by a donor device of adonor and that identifies a donee; accessing, using a donor publicledger address that is included in the multi-signature crypto-currencytransaction, a verified donor static key that is stored in a publicledger; generating a first donor authentication key using the verifieddonor static key and authentication attempt information associated withthe donor; confirming, in response to the first donor authentication keymatching a second donor authentication key that was received at anauthentication public ledger address included in the public ledger, averified donor identity of the donor; signing, in response to confirmingthe verified donor identity of the donor, the multi-signaturecrypto-currency transaction to provide a signed multi-signaturecrypto-currency transaction; broadcasting the signed multi-signaturecrypto-currency transaction to cause donation funds to be transferredfrom the donor to the donee; and sending, through the network to a doneedevice of the donee, a notification of the donation funds.
 2. The systemof claim 1, wherein the operations further comprise: receiving, throughthe network from the donor device, donor identity information; verifyingthe donor identity information to generate the verified donor statickey; and providing the verified donor static key on the public ledger.3. The system of claim 1, wherein the operations further comprise:receiving, through the network from the donee device, donee identityinformation; verifying the donee identity information to generate averified donee static key; and providing the verified donee static keyon the public ledger.
 4. The system of claim 1, wherein the broadcastingthe signed multi-signature crypto-currency transaction causes thedonation funds to be transferred via a public ledger from the donor tothe donee.
 5. The system of claim 1, wherein the donation funds aretransferred from the donor to the donee separately from a public ledgerthat identifies the multi-signature crypto-currency transaction.
 6. Thesystem of claim 1, wherein the operations comprise: providing systemprovider identity information for verification such that a verifiedsystem provider identity is included on the public ledger, wherein themulti-signature crypto-currency transaction is used to confirm theverified system provider identity.
 7. A method for anonymous donations,comprising: identifying, by a system provider device through a network,a multi-signature crypto-currency transaction that is provided by adonor device of a donor and that identifies a donee; accessing, by thesystem provider device using a donor public ledger address that isincluded in the multi-signature crypto-currency transaction, a verifieddonor static key that is stored in a public ledger; generating, by thesystem provider device, a first donor authentication key using theverified donor static key and authentication attempt informationassociated with donor; confirming, by the system provider device inresponse to the first donor authentication key matching a second donorauthentication key that was received at an authentication public ledgeraddress included in the public ledger, a verified donor identity of thedonor; signing, by the system provider device in response to confirmingthe verified donor identity of the donor, the multi-signaturecrypto-currency transaction to provide a signed multi-signaturecrypto-currency transaction; broadcasting, by the system providerdevice, the signed multi-signature crypto-currency transaction to causedonation funds to be transferred from the donor to the donee; andsending, by the system provider device through the network to a doneedevice of the donee, a notification of the donation funds.
 8. The methodof claim 7, further comprising: receiving, by the system provider devicethrough the network from the donor device, donor identity information;verifying, by the system provider device, the donor identity informationto generate the verified donor static key; and providing, by the systemprovider device, the verified donor static key on the public ledger. 9.The method of claim 7, further comprising: receiving, by the systemprovider device through the network from the donee device, doneeidentity information; verifying, by the system provider device, thedonee identity information to generate a verified donee static key; andproviding, by the system provider device, the verified donee a statickey on the public ledger.
 10. The method of claim 7, wherein thebroadcasting the signed crypto-currency transaction causes the donationfunds to be transferred via a public ledger from the donor to the donee.11. The method of claim 7, wherein the donation funds are transferredfrom the donor to the donee separately from a public ledger thatidentifies the multi-signature crypto-currency transaction.
 12. Themethod of claim 7, further comprising: providing, by the system providerdevice to the donee device, system provider identity information forverification.
 13. The method of claim 12, further comprising: verifying,by the donee device, the system provider identity information togenerate a verified system provider identity; providing, by the doneedevice, the verified system provider identity on the public ledger; andusing, by the donee device, the multi-signature crypto-currencytransaction to confirm the verified system provider identity.
 14. Anon-transitory machine-readable medium having stored thereonmachine-readable instructions executable to cause a machine to performoperations comprising: identifying, through a network, a multi-signaturecrypto-currency transaction that is provided by a donor device of adonor and that identifies a donee; accessing, using a donor publicledger address that is included in the multi-signature crypto-currencytransaction, a verified donor static key that is stored in a publicledger; generating a first donor authentication key using the verifieddonor static key and authentication attempt information associated withthe donor; confirming, in response to the first donor authentication keymatching a second donor authentication key that was received at anauthentication public ledger address included in the public ledger, averified donor identity of the donor; signing, in response to confirmingthe verified donor identity of the donor, the multi-signaturecrypto-currency transaction to provide a signed multi-signaturecrypto-currency transaction; broadcasting the signed multi-signaturecrypto-currency transaction to cause donation funds to be transferredfrom the donor to the donee; and sending, through the network to a doneedevice of the donee, a notification of the donation funds.
 15. Thenon-transitory machine-readable medium of claim 14, wherein theoperations further comprise: receiving, through the network from thedonor device, donor identity information; verifying the donor identityinformation to generate the verified donor static key; and providing theverified donor static key on the public ledger.
 16. The non-transitorymachine-readable medium of claim 14, wherein the operations furthercomprise: receiving, through the network from the donee device, doneeidentity information; verifying the donee identity information togenerate a verified donee static key; and providing the verified doneestatic key on the public ledger.
 17. The non-transitory machine-readablemedium of claim 14, wherein the broadcasting the signed multi-signaturecrypto-currency transaction causes the donation funds to be transferredvia a public ledger from the donor to the donee.
 18. The non-transitorymachine-readable medium of claim 14, wherein the donation funds aretransferred from the donor to the donee separately from a public ledgerthat identifies the multi-signature crypto-currency transaction.
 19. Thenon-transitory machine-readable medium of claim 14, wherein theoperations comprise: providing, to the donee device, system provideridentity information for verification.
 20. The non-transitorymachine-readable medium of claim 19, wherein the operations furthercomprise: verifying, by the donee device, the system provider identityinformation to generate a verified system provider identity; providing,by the donee device, the verified system provider identity on the publicledger; and using, by the donee device, the multi-signaturecrypto-currency transaction to confirm the verified system provideridentity.